To protect against single cluster failures due to scheduled or unscheduled maintenance, change requests, or disasters bringing down a cluster, and facilitate automatic failover, high-availability schemes have multiple worker jobs running in multiple clusters. A manually administered lock scheme or a manually initiated lock competition is used to elect a master from among the worker jobs. Such an approach does not provide for the ability to give preference to some workers in becoming master over other workers. It is currently not possible to automatically prefer workers which are situated closest to some arbitrary hub, such as a database (for instance, in order to minimize communication latency). It is also not currently possible, in such a master election scheme, to cause automatic failover to workers in the next-closest cluster if all the workers in the preferred cluster die or are unhealthy for any reason. Also in the context of master election based on communication latency minimization, it is not currently possible to avoid workers in an unhealthy cluster from becoming preferred even if they are closest to the hub. Also in the context of master election, it is not currently possible to “tether” the failover of a master worker to the failover of a hub based purely on preference and/or automated election parameters.
Current solutions to the above problems require a human watching the hub location, calculating which worker would be closest to the hub and accordingly bringing the worker jobs up/down in the cluster manually calculated to be preferred and healthy (and not affected by upcoming maintenance or change requests). But since this requires constant human involvement, this solution would be error prone and inefficient. An automated solution to the above problems is therefore desirable and preferable.